❯❯ spec-kit／BMAD／OpenSpec／sdd.os 比較：它們都停在「程式碼生出來了」

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（今日：先看別人的地圖）

在建構自身的工程流水線前，更準確地說，是在完成初版驗證之後，我曾針對現有的主流框架進行了一輪實測與調研。

那時完成公司運動科技專案二期，我的開發流程已具備基本雛形。剛好原本排定的婚紗外拍被多場暴雨延期（沒錯！就是延了四次இдஇ），多出來的空檔，我拿去測試新工具，選擇以一個無後端依賴的小型專案「晴天娃娃（TeruTeru）」作為標的，引入了當時熱門的 OpenSpec 框架。目前該專案的 GitHub 儲存庫中，仍保留著當時實作留下的 openspec/ 配置目錄。

實際套用的體感並不理想。晴天娃娃屬於業務邏輯極度輕量的小型專案，簡單來說就是輸入資訊 → 不斷點擊 → 結束頁面，而我當時採用的開發粒度為「一頁劃分為一個變更（Change）」。

在此顆粒度下，開發節奏表現為：

完成單頁實作 → 暫停開發 → 手動確認 → 變更歸檔 → 切換至下一頁。

雖然 OpenSpec 的變更追蹤（Change Tracking）機制非常嚴謹，但在小型專案中，這種高頻率的人工蓋章節奏頻繁中斷了開發者的專注流。

這類專案若連續開發，理想情況下可在 1 至 2 天內完成。但這次實測讓我明確感受到：人工確認點（Human-in-the-loop）並非越多越安全；若確認點設定於不適當的流程位置，將會嚴重切碎開發節奏，降低開發體驗（DX）。

至於 spec-kit 與 BMAD，我也深入研讀了其官方文件與相關實戰案例。本文的評估並非基於理論推演，而是建立在實際付過工程體感代價的測試基礎上。

現有框架的優勢分析

這類方法論統稱為 Spec-Driven Development（SDD，規格驅動開發）：將規格定義視為開發流程的唯一真理來源（Single Source of Truth），程式碼僅是規格實體化的產物。

近年熱門的框架均基於此思想，並各自發展出不同的著眼點：

• spec-kit：
  核心機制為「憲章（Constitution）」，透過預先確立品質約束與規範，限制 AI 在特定邊界內生成程式碼，防止架構過度工程化。
• BMAD：
  採用多角色分工架構，將 Analyst、PM、Architect、Dev、QA 等職責模組化，於 Terminal 中模擬小型開發團隊的協作流程。
• OpenSpec：
  專注於變更管理（Change Management），每次異動均經過 Proposal、Delta 比對、合併至主規格與 Archive 歸檔，提供清晰的規格演進歷史。
• sdd.os：（現更名為 SpecFormula）
  主打測試自動化，輸入規格後自動衍生測試案例，AI 的職責限定為編寫業務邏輯以通過測試（綠燈）。（也是我此套流水線設計最大的啟發參考）

上述框架各有優異的架構設計，我在規劃流水線時亦汲取了其中的核心思維（從前期研究到實際測試歷時約半年）。

共同的邊界：止步於「程式碼生成」

下表呈現了我進行技術選型時的分析快照（約半年多前）。雖然這些工具近期持續快速迭代（補述於後），但當時促使我自行開發流水線的核心原因，在於它們似乎都停在於相同的交付節點：

上述落點看似不同，本質上均停留在「程式碼已生成」的時間點。以架構圖表示如下：

規格 / Prompt ──> [ 程式碼生成 / 測試轉綠 ]   ← 現有框架到此為止
                           │
                           │  尚未涵蓋的工程空白：
                           │  ・修改 UI 樣式時，如何確保業務邏輯不被破壞？
                           │  ・後端規格變更時，如何進行增量同步而非全量覆蓋？
                           │  ・測試全綠情況下，如何防止正式站連線 DB 時潰散？
                           │  ・測試環境與生產環境的資料源與部署邏輯如何隔離？
                           ▼
                   [ 正式站穩定出貨 ]

近期這些框架亦進行了功能補強：spec-kit 新增了 /speckit.converge（比對 Codebase 與規格並衍生補強任務）與 /speckit.taskstoissues（將任務轉換為 GitHub Issues）；BMAD 進版至 v6，將 Code Review 與 Retrospective 納入 Implementation 階段；OpenSpec 則將合併至主規格獨立為 sync 步驟。

然而，上述補強大多仍集中於「程式碼編寫」維度。多數框架的主敘事仍停留在程式碼生成階段。但在實際產品開發中，專案往往不是失敗於初始程式碼的生成，而是失敗於後續的增量同步、樣式調整、部署門禁與防呆機制等營運細節。

角色視角：工程痛點的差異

從憲章、架構師到 Aggregate（聚合根） 與 Delta Spec（差異規格），現有許多框架的設計語言，本質上都是以後端工程師或系統架構師的思維為核心。

但對前端來說，真正卡關的工程痛點其實是：
當後端 API 還沒準備好時，我們該如何優雅地解耦、不被進度卡死？
又或者，在利用 AI 輔助建立跨領域的後端與資料庫結構時，我們該如何守住架構的安全性，避免種下技術債？

這些在前端開發日常中極具代表性的問題，卻往往是目前較少被深入探討的盲區。

流水線的定位：補齊後續工程護欄

本工程流水線的定位並非隨意創造一套全新方法論，而是為了填補現有流程中的銜接空白。

事實上，無論是「規格的生成與轉化」，或是將規格「實體化為程式碼」，既有的 SDD 框架與 AI 工具都已展現出成熟且高效的能力。然而，本流水線真正關注的，是 「程式碼生成之後」的工程護欄 ，這包括在修改 UI 時防範破壞規格違約的防禦機制、後端規格異動時的增量同步流程，以及透過 CI 閘門（Gate）確保通過測試的程式碼能平穩推進至生產環境。

在實測現有方案後更能確定，問題往往不在於工具本身的優劣，而是彼此的守備範圍不同。開發團隊真正需要的，不只是更強大的 Prompt 框架，更是當框架運行完畢後，能守住產品穩定運作的最後一道防線。

下一篇（Day 03），我將展開整套流程的全景圖，並明確劃定流水線的責任邊界。

📎 本篇證據｜TeruTeru GitHub Repository